User authentication using techniques such as passwords, one time passwords (OTPs), hardware or software smartcards, etc., have all proven to be either too weak and susceptible to man in the middle (MITM) or man in the browser (MITB) attacks, or else have proven too cumbersome and expensive. The use of single sign on techniques such as Open ID, FaceBook Connect, etc., only make the problem worse as once the attacker has compromised the master account they can now break into all other accounts that rely on that initial login. Further, the focus of attackers has shifted from trying to break the login process to using sophisticated techniques to come in after the act of login and to attack the transactions being performed. This has made transaction authentication, the act of confirming if the transaction seen at the back end web server is identical to that intended by the user, even more important.
Out of band authentication (OOBA), a technique by which a transaction is relayed to the user, and confirmation obtained, using an alternate form of communication, for instance by placing a voice phone call or a text message, is a promising alternative, but is also to inconvenient and costly to be used very often. It might be useful for the highest value transactions, or rare events like password resets, but using it for large numbers of transactions is too costly and cumbersome.
In our work, we developed innovations that address some of these problems. Specifically, we introduce the notion of the establishment of a security server that communicates with an independent pop-up window on the user's desktop that is being used to access the website. We determine how this security server can alert the user, via communications to the pop-up as to the legitimacy of the website the user is browsing via their browser. We also determine how this pop-up window can provide a user with a one time password to enable login into the website (i.e. authentication of the user to the website), based on a secret shared between the website and the security server. Of particular utility is the fact that it provide the security of one time passwords, but did not require a per user shared secret which all prior one time password systems have required. We refer to this using various terms, such as quasi out of band authentication (QOOBA), 2CHECK (2CHK) authentication, and Authentify authentication.
It is common when users browse an eCommerce website, such as a merchant, bank or broker website, for them to see Payment Buttons such as that provided by PayPal. When the user clicks on that payment functionality, the user is typically interacting directly with the payment provider. This means the user does not reveal their credentials, for authenticating to the payment provider, to the eCommerce site. This is an important feature that is no longer available when a user is interacting with the eCommerce site using a smart phone app the site provides.
Thus we extend that work to provide a separate secure client application which has an independent secure communication channel to a back end authentication server. This client application is sometimes referred to as the “QOOBA application” or the “QOOBAA” for short, “2CHK client”. or the “Authentify Application” or “AA” for short. This client application can be used to show users transactions either to inform them of the transaction, allow the user to confirm/deny the transaction and/or provide the user with a transaction signature which he/she can use in another application, such as a merchant or bank website application. Further, the client application can also provide the user with an OTP, that can be used to login to different websites or other applications. We also develop two distinct methods of generating such OTPs. One in which the OTP is provided by the authentication server, and the other in which the client application is “seeded” during activation so it can then generate OTPs without any connection to the backend authentication server.
Additionally, we determine how this client application can be implemented as dedicated software on a computing device, or as a browser based application, or as an application on a mobile communications device, including a smart phone.
The profusion of smart phones has resulted in the coming to market of adjunct pieces of hardware that can attach to the smart phones using various interfaces. Much like one can attach a printer to a computer using a USB port and/or cable, one can also attach devices to smart phones using for instance the ubiquitous headphone jack.
Below we will describe various examples of how key management can be beneficially layered on top of a QOOBA architecture. Our first example relates to digital signing. In applications that require digital signing, a user needs to be provisioned a private key and a digital certificate, i.e. a binding of the user's identity and public key as certified by a Certificate Authority. The use of such a private key, which is not known to any 3rd party, including the security server, provides for strong non-repudiation which is necessary for some applications. We follow the industry convention of referring to signatures created with public key cryptography as “digital signatures”. As will be understood by those skilled in the art, signatures based on underlying symmetric cryptography with shared secrets, like that which the QOOBA system as described above already provides, are usually referred to as “electronic signatures”.
One example relates to encrypted document delivery. When an encrypted file is sent to a user, for example a PDF of a brokerage statement, the user needs to be provided with the key with which the file was encrypted.
Another example relates token authenticators. When users are provisioned a token authenticator, either for a one time password generator or a transaction authenticator, the user's token needs to be provided with a shared secret key. Those skilled in the art will recognize that in this context, the shared secret key is often characterized as a “seed”).
In all these examples key management adds directly to the cost of the system, and indirectly effects the security. Keys need to be generated, distributed and maintained in sync. As keys can get lost, corrupted or stolen, key management is usually a significant source of costs, and a point of vulnerability in the system.
The innovations described herein also further extend our work to provide for efficient and secure login authentication and transaction authorization using plug-in hardware compatible with smart mobile communication devices and Internet connectable personal computing devices.